CVE-2026-35058 - fix server ASSERT() on receiving a suitably malformed packet with a valid tls-crypt-v2 key

tls-crypt-v2: Avoid interpreting opcode as part of WKc

The buffer we pass to tls_crypt_v2_extract_client_key contains the entire received control channel packet. We should skip the opcode before trying to read WKC.

This logic error is a second bug behind the XlabAI finding, next too the too-strict ASSERT in tls_crypt_unwrap.

Also remove a too strict ASSERT in tls_crypt_unwrap. We already check a few lines later for a too short packet and return a proper error ("packet too short").

XlabAI found a way of triggering this ASSERT that requires a tls-crypt-v2 client key that has a specific property (a specific byte need to have a specific value, about 1/256 probability). If an attacker can get hold of such a tls-crypt-v2 client key or observe a handshake using such a key, the attacker can trigger the ASSERT, crashing the server. Setups that do not use tls-crypt-v2 are not affected.

Independently, Cisco Talos reported a way to trigger this ASSERT with any tls-crypt-v2 key but this requires the attacker to be also in possession of the private key part of the tls-crypt-v2 client key or to inject packet into a live session of a client session.

OpenVPN version 2.6.0 through 2.6.19 and 2.7_alpha1 through 2.7.1 are affected. This is fixed in version 2.6.20 and 2.7.2.

CVE Record: CVE-2026-35058

Github: OpenVPN/openvpn-private-issues#111

Release notes: openvpn-2.7.2 openvpn-2.6.20

Reported-By: XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com)

Reported-By: Guannan Wang (wgnbuaa@gmail.com

Reported-By: Zhanpeng Liu (pkugenuine@gmail.com)

Reported-By: Guancheng Li (lgcpku@gmail.com)

Reported-By: Emma Reuter of Cisco ASIG (TALOS-2026-2381)